web-next/src/contexts/ViewerContext.tsx (1)

9-11: Use a named props interface for ViewerProvider.

The component works, but defining props inline here diverges from the repo’s TS props convention and reduces reuse/readability.

♻️ Proposed refactor

+interface ViewerProviderProps {
+  isAuthenticated: () => boolean;
+}
+
-export const ViewerProvider: ParentComponent<{
-  isAuthenticated: () => boolean;
-}> = (props) => {
+export const ViewerProvider: ParentComponent<ViewerProviderProps> = (props) => {

As per coding guidelines "Use interfaces for component props (e.g., ButtonProps) in TypeScript".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@web-next/src/contexts/ViewerContext.tsx` around lines 9 - 11, Replace the
inline props type on ViewerProvider with a named interface: create an exported
interface (e.g., ViewerProviderProps) that declares isAuthenticated: () =>
boolean, then update the component signature to
ParentComponent<ViewerProviderProps> and use that interface where the props type
is referenced (i.e., the ViewerProvider function definition and any related type
imports/exports) to follow the repo TS props convention and improve
reuse/readability.

graphql/schema.graphql (1)

1377-1383: Use stronger scalar types for URL-shaped fields in WebFingerResult.

iconUrl and url are URL values but currently typed as String, which weakens schema validation and client contract clarity.

♻️ Proposed schema refinement

 type WebFingerResult {
   domain: String
   emojis: JSON
   handle: String
-  iconUrl: String
+  iconUrl: URL
   name: String
   preferredUsername: String
   remoteFollowUrl: String
   software: String
   summary: String
-  url: String
+  url: URL
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@graphql/schema.graphql` around lines 1377 - 1383, The WebFingerResult type
uses plain String for URL-shaped fields; change the iconUrl and url field types
to a URL scalar (e.g., replace "iconUrl: String" and "url: String" with
"iconUrl: URL" and "url: URL"), ensure the URL scalar is declared/imported in
the schema (or add a GraphQL scalar type named URL that validates URLs), and
update any resolvers/type mappings that construct WebFingerResult (functions or
classes that return iconUrl or url) to return/validate a proper URL value or
string that passes the URL scalar validation.

web-next/src/components/RemoteFollowButton.tsx (1)

63-65: Destructure component props at the function boundary.

This keeps the component aligned with repo conventions and simplifies access across handlers.

♻️ Proposed refactor

-export function RemoteFollowButton(props: RemoteFollowButtonProps) {
+export function RemoteFollowButton(
+  { actorHandle, actorName }: RemoteFollowButtonProps,
+) {
@@
-          actorHandle: props.actorHandle,
+          actorHandle,
@@
-  const displayName = () => props.actorName || props.actorHandle;
+  const displayName = () => actorName || actorHandle;

As per coding guidelines "Files with components use PascalCase naming (e.g., Button.tsx) Use functional components with props destructuring".

Also applies to: 115-116, 144-145

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@web-next/src/components/RemoteFollowButton.tsx` around lines 63 - 65, The
component currently receives props via a single identifier; change
RemoteFollowButton to destructure its RemoteFollowButtonProps at the function
boundary (e.g., function RemoteFollowButton({ ... }: RemoteFollowButtonProps))
so handlers can use the props directly, update any internal references that
access props.* to the new local names, and apply the same props-destructuring
refactor to the other component declarations in this file that follow the same
pattern (the other component functions that currently accept a props
identifier).

graphql/webfinger.ts (1)

121-125: Add an explicit return type to lookupWebFingerImpl.

This function returns a complex object-or-null shape; please annotate it explicitly (ideally via a shared result type used by both buildWebFingerResult and fallback returns).

As per coding guidelines: **/*.{ts,tsx}: Use explicit typing for complex return types in TypeScript.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@graphql/webfinger.ts` around lines 121 - 125, Add an explicit TypeScript
return type for lookupWebFingerImpl that describes the complex object-or-null
shape it returns; define a shared interface or type alias (e.g., WebFingerResult
or IWebFingerResult) that matches the return shape produced by
buildWebFingerResult and use that type on lookupWebFingerImpl's signature and on
any fallback return values (including null if appropriate) so both
buildWebFingerResult and lookupWebFingerImpl reference the same result type.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

web-next/src/locales/zh-TW/messages.po (1)

1546-1549: Translation adds content not present in source string.

The source text "You are about to follow {0}." is translated as "你即將從你的帳戶關注{0}。" which back-translates to "You are about to follow {0} from your account." The phrase "從你的帳戶" (from your account) was added.

While this may provide helpful context in the UI, it deviates from the source string. Consider aligning with the source:

Suggested fix

 #. placeholder {0}: actor().name ?? actor().handle
 #: src/routes/(root)/authorize_interaction.tsx:127
 msgid "You are about to follow {0}."
-msgstr "你即將從你的帳戶關注{0}。"
+msgstr "你即將關注{0}。"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@web-next/src/locales/zh-TW/messages.po` around lines 1546 - 1549, The
translated string msgstr for msgid "You are about to follow {0}." adds extra
content ("從你的帳戶") not present in the source; update the msgstr to closely match
the source by removing that added phrase so it reads a direct equivalent of "You
are about to follow {0}." (e.g., "你即將關注{0}。"), preserving the placeholder and
punctuation used in the original msgid.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

graphql/webfinger.ts (1)

91-97: ⚠️ Potential issue | 🟡 Minor

One malformed emoji URL can abort all emoji extraction.

The new URL(raw) on line 91 is not guarded by its own try-catch. If any single emoji has a malformed URL, the exception propagates to the outer catch block (line 100), terminating the loop and skipping all remaining emojis.

🛠️ Proposed fix

         const emojiName = tag.name.toString();
         const raw = emojiIcon.url instanceof vocab.Link
           ? emojiIcon.url.href!.href
           : emojiIcon.url.href;
-        const u = new URL(raw);
-        if (
-          (u.protocol === "http:" || u.protocol === "https:") &&
-          !/[\'\"]/.test(raw)
-        ) {
-          emojis[emojiName] = u.href;
+        try {
+          const u = new URL(raw);
+          if (
+            (u.protocol === "http:" || u.protocol === "https:") &&
+            !/[\'\"]/.test(raw)
+          ) {
+            emojis[emojiName] = u.href;
+          }
+        } catch {
+          continue;
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@graphql/webfinger.ts` around lines 91 - 97, The loop that builds the emojis
map uses new URL(raw) unguarded, so a single malformed raw will throw and abort
processing; wrap the URL construction/validation for each emoji (the new
URL(raw) call inside the block that assigns emojis[emojiName]) in its own
try/catch (or pre-validate the string) and only assign emojis[emojiName] =
u.href when URL parsing succeeds and the protocol check passes, ensuring a
malformed emoji URL is skipped without breaking the outer loop or aborting the
whole extraction.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

web-next/src/routes/(root)/authorize_interaction.tsx (2)

27-30: ⚠️ Potential issue | 🟡 Minor

Normalize acct: URIs before calling actorByHandle.

If uri arrives as acct:user@host, this goes straight into actorByHandle, causing an avoidable failed lookup path and extra latency.

🔧 Proposed fix

 export const route = {
   preload(args) {
-    const uri = new URLSearchParams(args.location.search).get("uri") ?? "";
-    if (uri) {
-      void loadPageQuery(uri);
+    const rawUri = new URLSearchParams(args.location.search).get("uri") ?? "";
+    const uri = rawUri.replace(/^acct:/i, "");
+    if (uri) {
+      void loadPageQuery(uri);
     }
   },
 } satisfies RouteDefinition;
@@
-  const uri = () => searchParams.uri as string | undefined;
+  const uri = () => (searchParams.uri as string | undefined)?.replace(/^acct:/i, "");

Also applies to: 39-39, 69-70

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@web-next/src/routes/`(root)/authorize_interaction.tsx around lines 27 - 30,
The code passes raw "acct:" URIs into actorByHandle causing failed lookups;
before calling loadPageQuery and anywhere actorByHandle is invoked (e.g., where
uri or handle is sourced), detect and normalize strings starting with "acct:" by
stripping the "acct:" prefix (and URL-decoding/trimming) to produce "user@host"
or the expected handle format, then pass the normalized handle into
loadPageQuery/actorByHandle so lookups use the correct handle format and avoid
the extra failed path.

---

23-35: ⚠️ Potential issue | 🔴 Critical

Fix duplicate authorizeInteractionPageQuery identifier (lint blocker).

The type import and GraphQL document constant share the same name, which triggers noRedeclare and blocks lint/check.

🔧 Proposed fix

-import type { authorizeInteractionPageQuery } from "./__generated__/authorizeInteractionPageQuery.graphql.ts";
+import type {
+  authorizeInteractionPageQuery as AuthorizeInteractionPageQuery,
+} from "./__generated__/authorizeInteractionPageQuery.graphql.ts";
@@
-const authorizeInteractionPageQuery = graphql`
+const authorizeInteractionPageQueryDocument = graphql`
   query authorizeInteractionPageQuery($uri: String!) {
@@
 const loadPageQuery = query(
   (uri: string) =>
-    loadQuery<authorizeInteractionPageQuery>(
+    loadQuery<AuthorizeInteractionPageQuery>(
       useRelayEnvironment()(),
-      authorizeInteractionPageQuery,
+      authorizeInteractionPageQueryDocument,
       { uri },
     ),
@@
-  const data = createPreloadedQuery<authorizeInteractionPageQuery>(
-    authorizeInteractionPageQuery,
+  const data = createPreloadedQuery<AuthorizeInteractionPageQuery>(
+    authorizeInteractionPageQueryDocument,
     () => loadPageQuery(props.uri),
   );

#!/bin/bash
set -euo pipefail
file="$(fd -p 'authorize_interaction.tsx' web-next/src/routes | head -n1)"
rg -nP '\bauthorizeInteractionPageQuery\b' "$file"
sed -n '20,40p' "$file"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@web-next/src/routes/`(root)/authorize_interaction.tsx around lines 23 - 35,
The file declares a type import authorizeInteractionPageQuery and also a const
graphql document with the same name, causing a redeclare lint error; fix by
renaming one of them (e.g., alias the type import: import type {
authorizeInteractionPageQuery as authorizeInteractionPageQueryType } or rename
the graphql const to authorizeInteractionPageQueryDocument) and update any local
references to the renamed symbol (check the import line and the const
declaration for authorizeInteractionPageQuery and adjust usages accordingly).

graphql/webfinger.ts (2)

227-276: ⚠️ Potential issue | 🟠 Major

Add abuse controls for unauthenticated remote-follow lookups.

This resolver can trigger multiple outbound requests per call and is publicly reachable, so it should be rate-limited (or similarly throttled) to reduce abuse and scanning risk.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@graphql/webfinger.ts` around lines 227 - 276, The public resolver
lookupRemoteFollower (its resolve function) can be abused to trigger many
outbound requests; add throttling by checking an authentication/context rate
limit before calling lookupRemoteFollowerImpl. Specifically, in the resolve for
lookupRemoteFollower, use a per-client key (e.g., ctx.ip or ctx.auth?.userId or
ctx.apiKey) and invoke the existing rate limiter (e.g., ctx.rateLimiter.consume
or a new token-bucket) to allow only a small number of calls per time window; if
the limit is exceeded, log the event and return null/early error instead of
calling lookupRemoteFollowerImpl. Keep the validation of args.followerHandle and
actor lookup intact and apply the limiter before the outbound lookup to protect
lookupRemoteFollower and lookupRemoteFollowerImpl from abuse.

---

158-163: ⚠️ Potential issue | 🟠 Major

Harden ActivityPub link selection and validate URL scheme before lookup.

Current matching is too permissive (includes("activity")), and href is used for network fetch without explicit http/https validation.

🔧 Proposed hardening

-  const activityPubLink = webfingerResult.links?.find((link) =>
-    link.type === "application/activity+json" ||
-    (link.rel === "self" && link.type?.includes("activity"))
-  ) as WebfingerLink | undefined;
+  const activityPubLink = webfingerResult.links?.find((link) =>
+    link.rel === "self" &&
+    (
+      link.type === "application/activity+json" ||
+      link.type === 'application/ld+json; profile="https://www.w3.org/ns/activitystreams"'
+    )
+  ) as WebfingerLink | undefined;
 
   if (!activityPubLink?.href) return null;
+  let activityPubHref: string;
+  try {
+    const parsed = new URL(activityPubLink.href);
+    if (parsed.protocol !== "http:" && parsed.protocol !== "https:") return null;
+    activityPubHref = parsed.href;
+  } catch {
+    return null;
+  }
@@
-    const actorObject = await ctx.fedCtx.lookupObject(activityPubLink.href, {
+    const actorObject = await ctx.fedCtx.lookupObject(activityPubHref, {
       documentLoader,
     });
@@
-      url: new URL(activityPubLink.href),
+      url: new URL(activityPubHref),

#!/bin/bash
set -euo pipefail
file="$(fd -p 'webfinger.ts' graphql | head -n1)"
rg -nP 'includes\\("activity"\\)|lookupObject\\(activityPubLink\\.href' "$file"
sed -n '150,200p' "$file"

Also applies to: 190-192

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@graphql/webfinger.ts` around lines 158 - 163, The ActivityPub link selection
is too permissive and uses href for network calls without validating the URL
scheme; tighten the matching and reject non-http(s) hrefs before calling
lookupObject. Update the link find logic over webfingerResult.links to only
accept link.type === "application/activity+json" or (link.rel === "self" &&
link.type?.startsWith("application/activity+json")) (or other precise MIME
strings you expect), then after selecting activityPubLink validate its href by
parsing with the URL constructor and ensuring url.protocol is "http:" or
"https:"; if parsing fails or the protocol is not http/https return null instead
of passing the href to lookupObject(activityPubLink.href). Use the
activityPubLink variable name and the lookupObject call as the places to modify.

Configuration used: defaults

Review profile: CHILL

Plan: Pro